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Method and System for Changing a Subscription 
FIELD OF THE INVENTION 



The present invention relates to a method and system for changing a subscription 
information of a subscriber in a data network. In particular, the present invention 
5 relates to a change of a subscription in an Internet Protocol (IP) multimedia sub- 
system (IMS) environment. 



BACKGROUND OF THE INVENTION 



In order to achieve access independence and to maintain a smooth interoperation. 
with wired terminals across the internet, the IMS as specified e.g. in the 3GPP 

10 specification TS 23.228 has been developed to be conformant to IETF (Internet 
Engineering Task Force) "Internet Standards". The IP multimedia core network (IM 
CN) subsystem enables network operators of mobile or cellular networks to offer 
their subscribers multimedia services based on and built upon Internet applica- 
tions, services and protocols. The intention is to develop such services by mobile 

15 network operators and other 3 rd party suppliers including those in the Internet 
space using the mechanisms provided by the Internet and the IM CN subsystem. 
The IMS thus enables conversions of, and access to, voice, video, messaging, 
data and web-based technologies for wireless users, and combines the growth of 
the Internet with the growth in mobile communications. 

20 Fig. 1 shows an architecture of an IMS network according to the above 3GPP (3 rd 
Generation Partnership Project) specification. The architecture is based on the 
principle that the service control for home subscribed services for a roaming sub- 
scriber is in the home network HN, e.g. a Serving Call State Control Function (S- 
CSCF) is located in the home network HN. In Fig. 1 , a current or old S-CSCFo 10 

25 and a future or new S-CSCFn 12 are shown, between which a terminal device or 
user equipment (UE) 40 is to be transferred due to changed required capabilities 
resulting from a change in the subscriber profile of the UE 40. 

In general, an S-CSCF performs the session control service for the served UEs. It 
maintains a session state as needed by the network operator for support of the 
30 services. Within an operator's network, different S-CSCFs may have different func- 
tionalities. The functions performed by the S-CSCF during a respective session 
are e.g. registration, session flow management, charging and resource utilization 
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management. When a subscriber roams to a visited network VN, the visited net- 
work VN supports a Proxy-CSCF (P-CSCF) 30 which enables the session control 
to be passed to the respective S-CSCF located at the home network HN and pro- 
viding the service control. Furthermore, an Interrogating-CSCF (l-CSCF) 50 is pro- 
5 vided in the home network HN as a contact point within the operator's network for 
all connections destined to a subscriber of that network operator, or a roaming 
subscriber currently located within that network operator's service area. There may 
be multiple l-CSCFs within an operator's network. The functions performed by the 
l-CSCF 50 include assigning an S-CSCF to a user performing a registration pro- 
10 cedure, routing a request received from another network towards the S-CSCF, 
maintaining the address of an S-CSCF from a subscriber database, e.g. a Home 
Subscriber Server (HSS) 20 as shown in Fig. 1, and/or forwarding requests or re- 
sponses to the S-CSCF determined based on the address of change from the 
HSS 20. 

15 The P-CSCF 30 is the first contact point within the IMS. Its address is discovered 
by the UE 40 following a PDP (Packet Data Protocol) contact activation. The P- 
CSCF 30 behaves like a proxy, i.e. it accepts requests and services them inter- 
nally or forwards them on, possibly after translation. The P-CSCF 30 may also be- 
have as a User Agent, i.e. in abnormal conditions it may terminate and independ- 

20 ently generate transactions. The functions performed by the P-CSCF 30 are for- 
warding register requests received from the UE 40 to an l-CSCF, e.g. the l-CSCF 
50, determined using the home domain name as provided by the UE 40, and for- 
warding requests or responses to the UE 40. 

Further details regarding the functions of the different CSCF elements shown in 
25 Fig. 1 can be gathered from the above mentioned 3GPP-specification. 

According to the conventional network architecture in the above mentioned 3GPP 
Release 5 specification, the HSS 20 is not aware of the kind of capabilities a spe- 
cific S-CSCF has in the network. On the contrary, the HSS 20 knows what kind of 
capabilities an S-CSCF needs to support a specific subscriber. This information is 
30 stored in a subscriber profile of the specific subscriber. During an initial registration 
process of UE 40, the HSS 20 sends the required S-CSCF capabilities to the I- 
CSCF 50 and the actual selection of the S-CSCF is done by the l-CSCF 50. The 
selection at the l-CSCF 50 is performed on the basis of an information indicating 
the required capabilities and received from the HSS 20. 
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However, when there is a need for updating the subscriber profile e.g. in the S- 
CSCFo 10 currently serving the UE 40, the HSS 20 cannot know whether the se- 
lected S-CSCFo 10 is still capable of adequately serving the subscriber of the UE 
40. It may be possible that new capabilities required according to the new sub- 
5 scriber profile are not supported by the S-CSCFo 10. Another possibility is that the 
service provider has removed some service from the subscriber profile and thus 
has prevented the usage of this service or service part. 

If the capability of the S-CSCFo 10 does not meet with the updated subscriber pro- 
file, the subscriber is not able to use all subscribed services, or may received ser- 
10 vices which he or she is no longer willing to have. Furthermore, the subscriber 

may be charged for services which he or she has been cancelled. Moreover, if the 
network operator has denied services, the subscriber may still be able to use 
these services which he or she is no longer authorized to use. 

SUMMARY OF THE INVENTION 

15 It is therefore an object of the present invention to provide a method and system 
for changing a subscription, by means of which an adequate or matched serving 
function can be assured even after a change in the subscriber profile of a sub- 
scriber. 

This object is achieved by a method for changing a subscription information of a 
20 subscriber in a data network, said method comprising the steps of: 
detecting a change in said subscription information of said subscriber; 
checking whether a capability of a network element serving a terminal device of 
said subscriber is still in accordance with said changed subscription information; 
and 

25 initiating in response to the result of said checking step a registration procedure for 
registering said terminal device of said subscriber to a new serving network ele- 
ment. 

Furthermore, the above object is achieved by a system for changing a subscription 
information of a subscriber in a data network, said system comprising: 
30 detecting means for detecting a change in said subscription information of said 
subscriber; 
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checking means for checking whether a capability of a network element serving a 
terminal device of said subscriber is still in accordance with said changed sub- 
scription information; and 

initiating means for initiating in response to said checking means a registration 
5 procedure for registering said terminal device of said subscriber to a new serving 
network element. 

Additionally, the above object is achieved by a subscriber database for storing a 
subscription information of a subscriber of a data network, said database being 
arranged to detect a change in said subscription information and to initiate a regis- 
10 tration procedure for registering a terminal device of said subscriber to a new serv- 
ing network element in response to the result of the checking operation for check- 
ing whether a capability of a network element serving a terminal device of said 
subscriber is still in accordance with said changed subscription information. 

Accordingly, when a subscriber profile of a subscriber is updated or changed, a 
15 capability mismatch at the serving network element is automatically detected and 
a new serving network element having adequate capabilities is allocated by initiat- 
ing the registration procedure. Thereby, any new subscription information can be 
taken into account almost immediately when it has been configured or stored in 
the subscriber database of the data network. 

20 The checking step may comprise checking whether said serving network element 
is still capable of serving said terminal device of serving said terminal device of 
said subscriber in view of said changed subscription information. 

The detection step may be based on a detection of a subscriber profile update, or 
may be based on a detection of a subscription of said subscriber to a new service. 

25 According to an advantageous further development, the checking step may be 
performed on the basis of a capability information added based on said detection 
step to a response message of a registration procedure initiated by said terminal 
device. In this case, the registration procedure may be initiated by said terminal 
device in response to a de-registration procedure initiated when a change of said 

30 subscription information has been detected in said detection step. Alternatively, 
the registration procedure may be a periodic registration procedure initiated at 
predetermined intervals. 
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Preferably, a configuration information may be provided for determining sub- 
scribed services needing predetermined serving network elements. 

According to another advantageous further development, the checking step may 
comprise the steps of transmitting a capability query comprising at least one requi- 
5 red capability to the serving network element, comparing capabilities of the serving 
network element with the at least one required capability, and receiving an 
acknowledgement indicating the result of the comparing step from the serving 
network element. As an alternative, the checking step may comprise the steps of 
transmitting an information indicating at least one required capability and an identi- 

1 0 fication of said serving network element to an interrogating network element, 

checking at said interrogating network element whether said serving network ele- 
ment fulfills said at least one required capabilities, and receiving an acknowledge- 
ment indicating the result of said checking step from said interrogating network 
element. Then, a de-register message for de-registering the terminal device may 

15 be sent to the serving network element in response to the received results of the 
comparing step. A re-registration procedure may then be initiated by the terminal 
device in response to a message issued by the serving network element. In this 
case, the de-register message may include a cause information which indicates 
that the reason for de-registration was a need for changing the subscriber informa- 

20 tion. 

As an alternative to the network-initiated re-registration procedure, a selection 
function of the data network may be initiated using the at least one required capa- 
bility, and a resulting identification information of the new serving network element 
25 may be notified to a proxy network element connected to the terminal device. The 
notification may be performed using an identification of the proxy network element 
stored at a subscriber database. The identification may be requested from the 
serving network element using the de-register message. The selection function 
may be performed by an interrogating network element. 

30 As a further alternative, the checking step may be performed by requesting from 
the data network a capability list containing an information about required capabili- 
ties of serving network elements. In particular, the capability list may be requested 
from an interrogating network element. Thus, the checking means may be the in- 
terrogating network element, e.g. an l-CSCF of the IMS. The interrogating network 

35 element may be arranged to perform that checking operation based on a capability 
information received with a registration authorization response. 
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The detection means may be a subscriber database e.g. a HSS. Thus, the change 
of the subscriber profile at the subscriber database can be detected directly so as 
to check the capability and initiate a registration procedure, if required. 

The initiating means may be the subscriber database, wherein the registration 
5 procedure is initiated by initiating the selection function of the data network core, 
or alternatively, by issuing the de-register message. As an alternative, the initiating 
means may be an interrogating network element arranged to issue a register mes- 
sage to the new serving network element 

The subscriber database may be arranged to inhibit an unnecessary registration 
10 based on a configuration information provided at said database. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the following, the present invention will be described in greater detail based on 
preferred embodiments with reference to the accompanying drawings, in which: 

Fig. 1 shows a schematic network architecture in which the preferred embodi- 
1 5 ments of the present invention can be implemented; 

Fig. 2 shows a message signaling and processing diagram indicating a subscrip- 
tion change procedure according to a first preferred embodiment; 

Fig. 3 shows a message signaling and processing diagram indicating a subscrip- 
tion change procedure according to a second preferred embodiment; 

20 Fig. 4 shows a message signaling and processing diagram indicating a subscrip- 
tion change procedure according to a third preferred embodiment; and 

Fig. 5 shows a message signaling and processing diagram indicating a subscrip- 
tion change procedure according to a fourth preferred embodiment. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

25 The preferred embodiments will now be described on the basis of an IMS network 
architecture as shown in Fig. 1. 
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The IMS shown in Fig. 1 refers to a set of core network entities using the services 
provided by the packet-switched domain to offer multimedia services. The HSS 20 
is the master database for a given user and includes the functions of conventional 
home location registers (HLRs) as well as new functionalities specified to IP net- 
5 works, such as the IMS. The HSS 20 is the entity containing the subscription- 
related information to support the network entities actually handling calls and/or 
sessions. The home network HN may contain one or several HSSs depending on 
the number of mobile subscribers, on the capacity of the equipment and on the 
organization of the network. The HSS 20 may integrate heterogeneous informa- 

10 tion, and enable enhanced features in the core network to be offered to the appli- 
cation and services domain. In particular, the HSS 20 is responsible for holding 
user-related information, such as user identification, numbering and address in- 
formation, user security information, user location information, and user profile in- 
formation. Based on this information, the HSS 20 is also responsible of supporting 

15 the call control and session management entities of the different domains and 
subsystems, such as the IMS, a Radio Network Subsystem (RNS), etc. 

According to the preferred embodiments, a registration procedure for registering 
the UE 40 to the new S-CSCFn 12 is initiated if a capability check indicates that 
the current S-CSCFo 10 is no longer capable of serving the UE 40 after a change 

20 in the subscription information of the respective subscriber. This automatic or 

semi-automatic adaptation of the serving network element or entity in response to 
a capability check can be performed in various ways, as described in the following 
four preferred embodiments. When the subscription or subscriber profile is 
changed for a subscriber, e.g. the subscriber subscribes new service(s) it is possi- 

25 bte that the already assigned S-CSCFo 10 cannot support the new service(s). 

In order to assign a new S-CSCFn 12 capable for serving the subscriber, the fol- 
lowing procedure indicated in Fig. 2 can be performed according to the first pre- 
ferred embodiment. 

As shown in Fig. 2, the HSS 20 de-registers the subscriber by sending a corre- 
30 sponding de-register message via the S-CSCFo 10 to the UE 40 (steps 1 and 2), 
which will lead to a situation where the UE 40 automatically initiates a new initial 
registration procedure, because the de-register message contains a cause code 
which indicates the reason for de-registration. This cause code or cause informa- 
tion is added by the HSS 20 in response to the detection of a change in the sub- 
35 scription information or subscriber profile of the concerned subscriber. This will 
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lead to a situation where a new S-CSCF, e.g. the S-CSCFn 12, will be selected 
based on the new subscriber profile. In order to avoid unnecessary de- 
registrations, the HSS 20 may contain some configuration information used to de- 
termine what kind of services need special S-CSCFs. The UE 40 sends a registra- 
5 tion message for a new registration to the l-CSCF 50 (step 3). The l-CSCF then 
sends a registration authorization message to the HSS 20 (step 4). As the HSS 20 
knows that the subscription was changed, it sends a registration authorization re- 
sponse with the capability information and name of the current S-CSCFo 10 to the 
l-CSCF 50, instead of only the name of the S-CSCF 50 as in the conventional pro- 

10 cedure. It is noted that the HSS 20 may as well only send the capability informa- 
tion of the current S-CSCFo 10 (step 5). Then, the l-CSCF 50 may use both or 
only the S-CSCF capability information to decide which actions it has to take, i.e. 
whether to select a new S-CSCF or not (step 6). Based on the checking result, the 
l-CSCF 50 either sends a registration message to the current S-CSCFo 10 or to a 

15 selected new S-CSCFn 12 having the required capability (step 7). 

Thereby, the serving network function can be adapted to the changes in the sub- 
scriber profile of the concerned subscriber. If the old or current S-CSCFo 10 fulfills 
the S-CSCF capability requirements, the old S-CSCF 10 is selected during the 
new registration process. 

20 Fig. 3 shows a message signaling and processing diagram indicating a subscrip- 
tion change procedure according to the second preferred embodiment. In the sec- 
ond preferred embodiment, the HSS 20 does not initiate any actions before the UE 
40 sends a normal periodic registration message to the network, e.g. to the I- 
CSCF 50 (step 1). When the periodic registration, i.e. a registration authorization 

25 message arrives at the HSS 20 (step 2), the HSS 20 knows that the subscription 
was changed and sends a registration authorization response message containing 
a capability information and name of the current S-CSCFo 10 to the l-CSCF 50 
instead of only the name of the current S-CSCFo 10 (step 3). Also in the present 
case, it is noted that the HSS 20 may only send the capability information. The I- 

30 CSCF 50 uses both or only the S-CSCF capability information to decide which ac- 
tions it has to take, i.e. whether to select a new -CSCF, e.g. the new S-CSCFn 12, 
or not (step 4). In the case shown in Fig. 3, the new S-CSCFn 12 is selected by 
transmitting a register message to the S-CSCFn 1 2 (step 5) because the old as- 
signed S-CSCFo 10 does not fulfill the requirements in order to provide the appro- 

35 priate services for the subscriber of the UE 40. 
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ln the above described first and second preferred embodiments, the automatic re- 
registration may be accompanied by a new functionality to clear the name of the 
old S-CSCFo 10 from the HSS 20 or to provide a corresponding flag information. 

According to the following third and fourth preferred embodiments, the HSS 20 first 
5 checks whether the current S-CSCFo 10 supports the new requirements needed 
by the changed subscriber profile or subscription information and initiates a corre- 
sponding subscriber profile or serving entity selection or change procedure, based 
on the result of the checking operation. If the current S-CSCFo 10 can support the 
new requirements, the new subscriber profile is updated in the current S-CSCFo 
10 10. If the current S-CSCFo 10 cannot support the new requirements, then the HSS 
20 starts a procedure leading to a change to the new S-CSCFn 12. It is noted that 
in the third and fourth preferred embodiments it is assumed that the UE 10 is lo- 
cated in the visited network VN and connected via the P-CSCF 30. 

According to the third preferred embodiment, a network-initiated de-register pro- 
15 cedure is started, which leads to a situation where the UE 40 automatically initi- 
ates a new initial re-registration procedure due to the fact that a de-register mes- 
sage issued by the HSS 20 contains a cause code which unambiguously reveals 
the reason for the de-registration. This leads to a situation where the new S- 
CSCFn 12 will be selected based on the new subscriber profile. 

20 Fig. 4 shows a message signaling and processing diagram indicating a subscrip- 
tion change procedure according to the third preferred embodiment. When a new 
subscriber profile has been issued, the HSS 20 sends a capability query to the 
currently selected S-CSCFo to (step 1). The capability query contains the new 
required capabilities. It is noted that this operation could be added to the existing 

25 profile uploading from the HSS 20 to the current S-CSCF 10 or it could be a new 
mechanism between the HSS 20 and the current S-CSCFo 10. The current S- 
CSCFo 10 compares its own capabilities to the required capabilities and makes a 
decision whether it can support the required capabilities, or not. Then, the current 
S-CSCFo 10 sends a capability response to the HSS 20, including a positive or 

30 negative acknowledgement (step 2). If the current S-CSCFo 10 cannot serve the 
subscriber anymore due to lack of capabilities, it will send a negative acknowl- 
edgement. If the current S-CSCFo 10 can still serve the subscriber, it will send a 
positive acknowledgement to the HSS 20. If a new subscriber profile was send, a 
current S-CSCFo 1 0 may store it for further use. 
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If the HSS 20 receives a positive acknowledgement, then it ends the selection or 
change procedure. If the subscriber profile was not sent in step 1, then the HSS 20 
starts a subscriber profile uploading procedure as specified in the above men- 
tioned 3GPP specification. 

5 If the HSS 20 receives a negative acknowledgement, it initiates a network-initiated 
de-registration process by sending a de-register message to the current S-CSCFo 
10 with a cause code which clearly identifies that the reason was a need for updat- 
ing the subscriber profile (step 3). The current S-CSCFo 10 receives the message 
from the HSS 20 and generates an appropriate SIP (Session Initiation Protocol) 

10 message, e.g. a NOTIFY message, with an appropriate cause code and sends it 
to the P-CSCF 30 (step 4). The P-CSCF 30 then forwards the SIP message to the 
UE 40 (step 5). This allows the UE 40 to automatically and Immediately start a re- 
registration procedure. In particular, the UE 40 receives the SIP message transmit- 
ted in steps 4 and 5 and detects the need for registration. Then, the UE 40 starts a 

15 registration process as specified in the above mentioned 3GPP specifications 
(step 6). Thereby, an adequate serving network entity can be selected. 

According to the fourth preferred embodiment, the HSS 20 starts a new procedure 
which would change the assigned current S-CSCFo 10 to the new S-CSCFn 12 
supporting the new requirements without involving the UE 40. It may be possible 
20 that the network is not able to deliver the network initiated de-register message to 
the UE 40, e.g. if the UE 40 has not been subscribed to a registration event report 
package. 

Fig. 5 shows a message signaling and processing diagram indicating a subscrip- 
tion change procedure according to the fourth embodiment. When a new sub- 

25 scriber profile has been issued, the HSS 20 sends a capability query to the current 
S-CSCFo 10 (step 1). The capability query contains new required capabilities ac- 
cording to the new subscriber profile. Also in the present case, the operation could 
be added to the existing profile uploading from the HSS 20 to the current S- 
CSCFo 10 or it could be a new mechanism between the HSS 20 and the current 

30 S-CSCFo 10. 

Having received the capability query, the current S-CSCFo 1 0 compares its own 
capabilities to the required capabilities and makes a decision whether it can sup- 
port the required capabilities, or not. If the current S-CSCFo 10 cannot anymore 
serve the subscriber due to lack of capabilities, it will send a capability response 
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with a negative acknowledgement to the HSS 20 (step 2). If the current S-CSCFo 
10 can still serve the subscriber, it will send a positive acknowledgement to the 
HSS 20. If a new subscriber profile was sent to the current S-CSCFo 10, then it 
stores it for further use. 

5 If the HSS 20 receives a positive acknowledgement, it ends the procedure. 

If the subscriber profile was not sent in step 1 , then the HSS 20 starts a subscriber 
profile uploading procedure as specified in the above mentioned 3GPP specifica- 
tions. 

If the HSS 20 receives a negative acknowledgement, as indicated in Fig. 5, the 
10 HSS 20 sends a de-register message to the current or old S-CSCFo 10 which cur- 
rently serves the subscriber of the UE 40. This message contains a request for the 
address and/or name of the P-CSCF 30 of the visited network VN (step 3). The 
current S-CSCFo 10 receives the de-register message and acknowledges the 
message with the address and/or name of the P-CSCF 30 (step 4). The current S- 
15 CSCFo 10 may then delete the existing subscriber profile of the concerned sub- 
scriber. Due to the fact that the de-register message contained a request to send 
the address and/or name of the P-CSCF 30, the current S-CSCFo 10 does not 
send any notification to the P-CSCF 30. The HSS 20 receives the acknowledge- 
ment with the address and/or name of the P-CSCF 30 and temporarily stores the 
20 subscribers' P-CSCF address and/or name (step 5). It is noted that the address 
and/or name of the P-CSCF 30 may be stored permanently in the HSS 20. Then, it 
is not necessary for the HSS 20 to request the address and/or name of the P- 
CSCF 30 in step 3. 

In step 6, the HSS 20 sends a message to the l-CSCF 50, including the subscriber 
25 identity and new capabilities required by the subscriber according to the changed 
subscription information. This message may be a message to initiate a selection 
function for selecting a new serving entity. In response to the receipt of the mes- 
sage, the l-CSCF 50 initiates a new S-CSCF selection for the subscriber based on 
the new required capabilities (step 7). Then, the l-CSCF 50 sends a register mes- 
30 sage to the newly selected S-CSCFn 12 including the subscriber identity (step 8). 
In response thereto, the new S-CSCFn 12 starts a subscriber profile uploading 
procedure as specified in the above mentioned 3GPP specification (steps 9 to 12). 
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When the subscriber profile has been updated, the new S-CSCFn 12 generates an 
appropriate SIP message, e.g. a NOTIFY message, including the address of the 
new S-CSCFn 12, and sends it to the P-CSCF 30 (step 13). In step 14, the P- 
CSCF 30 stores or updates the S-CSCF address to be used in future sessions 
5 (step 14). Finally, the P-CSCF 30 acknowledges to the new S-CSCFn 12 with a 
SIP 200 OK message, the new S-CSCFn 12 acknowledges to the l-CSCF 50 with 
a SIP 200 OK message, and the l-CSCF 50 sends a corresponding acknowl- 
edgement to the HSS 20. Then, the serving network entity has been adapted to 
the changed subscriber profile. 

10 The capability checking operation performed by the HSS 20 in the third and fourth 
preferred embodiment may be replaced by the following checking procedure. Ac- 
cording to this alternative checking procedure, the HSS 20 may send a query for a 
capability list to the l-CSCF 50. This message may contain the required capabili- 
ties of the new S-CSCF. Then, the l-CSCF 50 checks the required capabilities and 

15 reports the list of available S-CSCFs to the HSS 20. The HSS 20 then checks if 
the current S-CSCFo 10 is included in this capability list. 

As a further alternative checking procedure, the HSS 20 may send the address of 
the current or old S-CSCFo 10 together with the new required capabilities accord- 
ing to the updated or changed subscriber profile to the l-CSCF 50 in a correspond- 

20 ing updating message, in a first step. Then, in a second step, the l-CSCF 50 ac- 
knowledges to the HSS 20 whether the old S-CSCF 10 fulfills the new require- 
ments). Based on the acknowledgement received from the l-CSCF 50, the HSS 
20 may then act in the following alternative ways. If the requirement(s) is/are ful- 
filled by the old S-CSCFo 10, a profile update from the HSS 20 to the l-CSCF 50 is 

25 initiated. If not, the HSS 20 initiates a network initiated de-registration procedure or 
S-CSCF selection procedure as described in connection with Figs. 4 and 5, re- 
spectively. 

The need for capability negotiation may be decreased by using a default S-CSCF 
instead of the capability based selection. Thus, when it is detected that the current 
30 S-CSCFo 10 is not capable of serving the subscriber in view of the changed sub- 
scription information, the default S-CSCF could be selected. 

Furthermore, the capability query of the HSS 20 may be integrated to an existing 
PPR diameter command in the Cx interface between the HSS 20 and the S-CSCF 
and/or l-CSCF functionality. 
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If the UE 40 cannot be informed to make a new registration in the third preferred 
embodiment, the P-CSCF 30 may initiate the new registration after receiving the 
notifying message. Then, the only element which requires changes would be the 
P-CSCF 30. 



5 As a further alternative, the HSS 20 may know all capabilities of the S-CSCFs pro- 
vided in the network. To achieve this, a corresponding table may be stored at the 
HSS 20. Then, the capability queries either from the l-CSCF 50 or the current S- 
CSCFo 10 would not be required in the third and fourth preferred embodiments. 
The checking operation may then be performed within the HSS 20. Moreover, if 
10 the HSS 20 contains some configuration information, unnecessary de-registrations 
can be avoided. 



Additionally, in the context of a subscriber profile update it may be notified that the 
old S-CSCF 10 does not support a new subscriber profile allocated thereto. Then, 
a change of the S-CSCF may be initiated based on a negotiating procedure similar 
15 to the capability queries of the first and second embodiments. I.e., if the old S- 
CSCF 10 receives the new subscriber profile from the HSS 20, it sends an ac- 
knowledgement message which may contain a reason, e.g. "service failed" or "ser- 
vice not known" etc., to the HSS 20, indicating that it does not support this kind of 
profile. 

20 It is noted that the present invention is not restricted to the preferred embodiments 
described above. The present invention may be implemented in any data network, 
where a subscription information of a subscriber has impact on the required capa- 
bilities of the serving network element. Thus, the designations and functions of the 
network elements or entities and signaling messages may be different in other or 

25 future data networks. The embodiments may thus vary within the scope of the at- 
tached claims. 



